\fi-420\li420 Q: I am writing an application which takes large blocks of bitmap data and blasts it to the screen. The data is basically in bitmap form generated by my program. I don't want to redraw the data, just transfer the pixels to the framebuffer. I have written a prototype of my application using NXImageBitmap(). It works fine, but I would like something faster.\
\
\fi0 Is there any way to get the data to the framebuffer faster than NXImageBitmap()? I have seen references in the Release 2.0 documentation to "out-of-band-messaging" to the WindowServer, although I have not been able to locate more information about this function.\
\i\li0 \
\i0\fi-420\li420 A: In 2.0, NXImageBitmap() has been improved to use out-of-band messaging to transfer image data to the WindowServer. This effectively eliminates most of the communication overhead of transferring raster data to the WindowServer (the memory is merely mapped into the WindowServer's address space by Mach). Once PostScript sees the data, it is rendered. It is most optimal if the rendering operation can be reduced to a simple one-to-one memory transfer; otherwise it must go through the general image rendering code. Therefore the best case of 'blasting' bitmaps to a window consists of:\
\
\fi-160\li580 • Use NXImageBitmap(), or the NXBitmapImageRep class, which provides the same performance but through a higher level API.\
• Be sure that the concatenation of the CTM in the graphics state and the image transformation is the identity (ie. no scaling, rotation or flipping of samples is involved).\
• Be sure that no transfer function is in effect.\
• Be sure that the data is the same depth as the screen (ie. 2-bit gray for NeXTstations).\
• For an image which contains no alpha, use a Retained window to avoid flushing (an extra copy of the data); otherwise use a Buffered window. [If the image contains alpha, it goes to the backing store anyway and is flushed more often.]\
\
\fi0\li420 If all of these conditions are met, the data should be moved from the application's memory buffer to VRAM with exactly one copy. (If you are using a Buffered window, two copies will be needed to show the image, but flashing can be avoided by waiting to flush until a bunch of images are rendered... All the usual tradeoffs with buffered windows...)\
\
If the application wants the depth of its virtual frame buffer to be independent of the hardware, then clearly someone must do bitmap conversion in order to put the data on screen. In 2.0, the WindowServer supports 2-bit and 32-bit window backing stores quite efficiently, so an application can use either of these depths for its window (using the
\f3\fs24 setwindowdepthlimit
\f2\fs28 operator) and the same depth for its virtual buffer and be assured of nearly optimal performance on all platforms. The flip side to this independence of course is that if a mismatch occurs (for example, an application with a virtual 24-bit backing store running on a NeXTstation 2-bit display) bitmap conversion needs to happen and the application will seem to perform slower. When forcing the WindowServer to use a certain depth backing store it is better to use buffered windows. This allows the application full control over flushing to the screen (which is when the conversion to the screen depth takes place).\
\
NOTE: There is a useful MiniExample called Winfo that can be used to determine window depth and memory usage for all windows currently running in the WindowServer. (See the NextAnswer misc.727 for instructions on obtaining MiniExamples from the archive servers.)\
